Review requested:

• @nodejs/loaders

@nodejs/process

in worker threadsx this is set to the entrypoint of the worker?

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.12%. Comparing base (6a3d80f) to head (992b11a).
⚠️ Report is 44 commits behind head on main.

@@            Coverage Diff             @@
##             main   #64800      +/-   ##
==========================================
- Coverage   90.16%   90.12%   -0.05%     
==========================================
  Files         744      744              
  Lines      242518   242571      +53     
  Branches    45705    45695      -10     
==========================================
- Hits       218670   218615      -55     
- Misses      15357    15443      +86     
- Partials     8491     8513      +22     

in worker threadsx this is set to the entrypoint of the worker?

This is set to the entrypoint of the process that created the worker, not the worker itself. So if /my/path/index.js creates /my/worker/index.js, entrypoint will a URL of /my/path/index.js.

in worker threadsx this is set to the entrypoint of the worker?

This is set to the entrypoint of the process that created the worker, not the worker itself. So if /my/path/index.js creates /my/worker/index.js, entrypoint will a URL of /my/path/index.js.

this is behaviorally different from the old "require.main".

Can we have the same?

IMO it makes more sense to show the entrypoint of the process, not the worker

I'm saying this is not identical to require.main, or what import.main is defined.

The issue linked refers to require.main.

Okay, I've changed Fixes to Ref, since I feel that it makes more sense to show it this way

Opened #64903 with the thread-scoped counterpart (module.entrypoint in node:module), matching require.main semantics.